69精品人人人人,一本色道久久综合亚州精品蜜桃,成人亚洲性情网站WWW在线观看,久久国产乱子伦免费精品无码

背景

轉(zhuǎn)轉(zhuǎn)作為一個(gè)初創(chuàng)公司，在成長(zhǎng)過程中，面臨著大量的運(yùn)營(yíng)活動(dòng)頁(yè)面以及MVp (Minimum Viable product，最小可執(zhí)行產(chǎn)品)項(xiàng)目。這類項(xiàng)目技術(shù)上雖然沒有多復(fù)雜，但卻讓我們頭疼不已，主要有這幾個(gè)原因:

項(xiàng)目的這些特點(diǎn)，在前期給了我們很大的壓力。馬不停蹄的上線，頻繁的修改，技術(shù)的成長(zhǎng)等，都讓我們有了一些疲憊。

后來(lái)，經(jīng)過了半年的磨礪，漸漸的我們沉淀出了一些工具與經(jīng)驗(yàn)，來(lái)從容的應(yīng)對(duì)這類型項(xiàng)目，先來(lái)看看我們的整體技術(shù)架構(gòu)圖：

針對(duì)上圖我們仔細(xì)講解一下。

運(yùn)營(yíng)技術(shù)能力架構(gòu)解讀

首先是通用需求模板，雖說(shuō)這和前端技術(shù)沒太大關(guān)系，但實(shí)踐證明，協(xié)助產(chǎn)品整理出一個(gè)需求模板至關(guān)重要。因?yàn)轫?xiàng)目著急時(shí)候，總是容易出現(xiàn)需求遺漏或不清晰的情況，如果后期修改的話，成本會(huì)很高。我們?cè)缙跁r(shí)候也總是會(huì)遇到遺漏埋點(diǎn)統(tǒng)計(jì)以和遺漏投放平臺(tái)的兼容性一類的需求。自從有了固定模板后，這類問題得到了根本的改善。

UI部分

我們使用photoshop作為主要的切圖工具，輔佐以Cutterman，借助其快捷的圖層和組操作，實(shí)現(xiàn)了切圖效率的提升。

業(yè)務(wù)技術(shù)部分

大部分運(yùn)營(yíng)類項(xiàng)目都有一定的模式，所以我們開發(fā)了一個(gè)組件化的頁(yè)面生成系統(tǒng)，取名“魔方”。這個(gè)系統(tǒng)可以支撐我們絕大部分運(yùn)營(yíng)類頁(yè)面的自動(dòng)生成，運(yùn)營(yíng)人員可以使用魔方自己搭建個(gè)性化頁(yè)面，讓開發(fā)成本直接降到0，后面會(huì)重點(diǎn)講下這個(gè)系統(tǒng)。

除了相對(duì)較為標(biāo)準(zhǔn)的模板型頁(yè)面，我們也會(huì)碰到許多個(gè)性化運(yùn)營(yíng)頁(yè)面需求，對(duì)于這部分需求，我們做了以下工具/庫(kù)來(lái)保證業(yè)務(wù)的快速開發(fā):

腳手架是我們得以快速開發(fā)的利器，現(xiàn)代前端開發(fā)越來(lái)越復(fù)雜，項(xiàng)目的前期搭建成本不低，一個(gè)好的種子項(xiàng)目(project-seed)，可以讓開發(fā)的時(shí)候只需要關(guān)注核心業(yè)務(wù)，無(wú)需被繁瑣的配置干擾。

UI庫(kù)也是必需品，各個(gè)公司通常都會(huì)有一個(gè)自己的業(yè)務(wù)UI庫(kù)。可能封裝的不是那么完美，但一定能解決大部分業(yè)務(wù)問題。

終端ApI適配庫(kù)主要是解決頁(yè)面容器的接口統(tǒng)一問題，比如設(shè)置分享信息。微信/微博/手Q以及我們自己的App等都不一樣，需要有個(gè)庫(kù)來(lái)適配。

除了前端頁(yè)面部分，我們還使用了Nodejs開發(fā)部分業(yè)務(wù)的后端接口，實(shí)踐發(fā)現(xiàn)，針對(duì)某些后端邏輯較弱的業(yè)務(wù)，使用Noejs可以讓我們的效率得到很大的提升，這點(diǎn)后面我們也會(huì)具體講下。

組件化開發(fā)平臺(tái)

運(yùn)營(yíng)類項(xiàng)目應(yīng)該優(yōu)先使用模板生成，這已是一個(gè)業(yè)界的共識(shí)，剩下的問題就是如何開發(fā)一個(gè)頁(yè)面模板平臺(tái)了。組件化開發(fā)平臺(tái)如下圖所示：

UI相對(duì)簡(jiǎn)陋，但功能還是很健全的。操作起來(lái)也很簡(jiǎn)單，以組件為維度，運(yùn)營(yíng)人員添加/編輯組件，預(yù)覽無(wú)誤后，最后發(fā)布頁(yè)面，服務(wù)器會(huì)根據(jù)運(yùn)營(yíng)配置的信息，進(jìn)行頁(yè)面的構(gòu)建，最后把構(gòu)建結(jié)果分發(fā)到相應(yīng)的服務(wù)器，就實(shí)現(xiàn)了一個(gè)頁(yè)面的發(fā)布。

在前端組件化開發(fā)的大潮下，我們以組件為維度開發(fā)了這個(gè)平臺(tái)。

在我們看來(lái)，頁(yè)面就是由各個(gè)組件來(lái)組成，一個(gè)組件就像一個(gè)函數(shù)，它接收數(shù)據(jù)，返回頁(yè)面。運(yùn)營(yíng)人員在我們的平臺(tái)選擇組件，其行為類似于import一個(gè)包，然后編輯配置，也就是給組件傳入數(shù)據(jù)，當(dāng)確定組件和數(shù)據(jù)之后，我們自然可以把組件渲染出來(lái)。

確定了組件的模式之后，隨之而來(lái)的第一個(gè)問題，便是組件的存儲(chǔ)形態(tài)。一個(gè)組件，它應(yīng)該是一個(gè)JSX文件？還是一個(gè)NpM包？又或者其他？這個(gè)問題讓我們產(chǎn)生了糾結(jié)。

在經(jīng)過了激烈的討論之后，我們最后決定使用NpM包來(lái)表述一個(gè)組件。依托于NpM完善的發(fā)布/拉取，以及版本控制機(jī)制，可以讓我們少做一些額外的工作，快速的把平臺(tái)搭建起來(lái)。當(dāng)這點(diǎn)確定之后，我們的整個(gè)開發(fā)流程如下：

開發(fā)人員使用我們的組件腳手架來(lái)開發(fā)組件，一個(gè)組件通常包括UI顯示部分與配置部分，當(dāng)開發(fā)完成時(shí)，便可以把組件發(fā)布在我們的私服npm上。進(jìn)入魔方組件管理頁(yè)面，添加該組件，得益于Webpack的動(dòng)態(tài)加載機(jī)制，運(yùn)營(yíng)人員在接下來(lái)的頁(yè)面設(shè)計(jì)中可以使用該組件。在魔方中新建一個(gè)頁(yè)面，添加我們剛剛更新的組件，然后進(jìn)行一系列的配置。發(fā)布該頁(yè)面，魔方的后臺(tái)Server會(huì)根據(jù)配置信息，比如使用了哪些組件，每個(gè)組件的配置等，導(dǎo)出一個(gè)JSON文件。根據(jù)JSON文件，調(diào)用腳本，然后使用Webpack去構(gòu)建出頁(yè)面，最后分發(fā)到服務(wù)器。因?yàn)槭窃诜?wù)端構(gòu)建生成頁(yè)面，這樣也節(jié)省了用戶打開頁(yè)面時(shí)，拉取初始化配置信息接口的過程，大大減少了白屏?xí)r間。

最后我們?cè)倏匆豢茨Х较到y(tǒng)的技術(shù)架構(gòu)，如下圖：

這是我們系統(tǒng)目前架構(gòu)圖，支撐了我們部分運(yùn)營(yíng)類型頁(yè)面，由組件為核心，一方面組件和UI庫(kù)打通，另一方面配置部分導(dǎo)出ApI，可以提供給其余端用（小程序、RN、客戶端等）。然后魔方平臺(tái)通過CNpM拉取組件，給運(yùn)營(yíng)人員提供一個(gè)可視化頁(yè)面編輯平臺(tái)。

魔方系統(tǒng)我們還在不斷的迭代中，它肯定有很多設(shè)計(jì)不好的地方，十分歡迎大家一起來(lái)討論。

Nodejs中間層

現(xiàn)在越來(lái)越多的公司使用Nodejs，目的各異。我們也使用了Nodejs，其中一個(gè)目的在于提高個(gè)性化運(yùn)營(yíng)項(xiàng)目的開發(fā)效率。我們大部分運(yùn)營(yíng)項(xiàng)目，對(duì)于后端的需求并不高。通常是做一些簡(jiǎn)單的存儲(chǔ)和調(diào)用一下底層的服務(wù)，比如領(lǐng)紅包，抽獎(jiǎng)，查詢商品等。這些服務(wù)都有成熟的底層接口，所以在應(yīng)用層來(lái)說(shuō)，邏輯就十分的少了。RD來(lái)做的話，可能半天一天開發(fā)完了，但是要花更多的時(shí)間在需求評(píng)審溝通，測(cè)試上線驗(yàn)收等階段，十分浪費(fèi)時(shí)間。如果這部分邏輯如果交由FE用Nodejs實(shí)現(xiàn)，可以有效減少溝通聯(lián)調(diào)時(shí)間，更重要的是節(jié)省了人力。我們項(xiàng)目后端使用的是JAVA，所以這里我們做了一層Nodejs中間層，來(lái)實(shí)現(xiàn)了Nodejs與Java的互通。

關(guān)于Nodejs和Java交互方式，我們之前寫過一篇文章，感興趣可以看看實(shí)戰(zhàn)系列之Node.js玩轉(zhuǎn)Java

前端監(jiān)控

運(yùn)營(yíng)類項(xiàng)目追求效率，這樣很容易導(dǎo)致質(zhì)量不佳。前期我們往往把質(zhì)量完全寄托于QA的把關(guān)以及開發(fā)人員的技術(shù)水平，但長(zhǎng)遠(yuǎn)來(lái)看，線上頁(yè)面的監(jiān)控也是一個(gè)不可或缺的角色。

監(jiān)控主要有兩方面：

性能監(jiān)控能很好的幫我們把關(guān)頁(yè)面的性能，轉(zhuǎn)轉(zhuǎn)FE支撐團(tuán)隊(duì)研發(fā)了一套性能監(jiān)控系統(tǒng)。以插件的形式，在入口文件引入后，會(huì)通過高階組件形式，Hook頁(yè)面組件的生命周期。通過performance ApI，獲得各個(gè)階段的數(shù)據(jù)，通過埋點(diǎn)的方式，向后臺(tái)發(fā)送數(shù)據(jù)，并展示。

異常監(jiān)控部分，以Webpack插件的形式，在生成HTML的時(shí)候，給代碼加上錯(cuò)誤監(jiān)控sdk，并格式化錯(cuò)誤信息，發(fā)送給后臺(tái)展示。原理是使用window.onerror監(jiān)聽頁(yè)面的錯(cuò)誤。這里面也會(huì)需要處理一些問題，比如跨域script的錯(cuò)誤捕捉，壓縮代碼使用sourcemap的還原等。

后記

以上這些就是我們高效開發(fā)運(yùn)營(yíng)類活動(dòng)的經(jīng)驗(yàn)了。對(duì)于成熟的公司來(lái)說(shuō)，這些系統(tǒng)可能很早就有了，并且十分強(qiáng)大。但對(duì)于轉(zhuǎn)轉(zhuǎn)來(lái)說(shuō)，一切還需要我們根據(jù)實(shí)際業(yè)務(wù)一步步完善。

效率是一個(gè)永恒的話題，下個(gè)階段，我們會(huì)針對(duì)更多元化的頁(yè)面（比如動(dòng)畫類），去找出它們的通用點(diǎn)，沉淀下來(lái)，讓我們的效率得到更高的提升，也歡迎大家一起來(lái)交流。

作者簡(jiǎn)介：

黃家興，轉(zhuǎn)轉(zhuǎn)前端運(yùn)營(yíng)組負(fù)責(zé)人。